1. Field of the Invention
The present invention relates to the field of requirements planning and more particularly to automated management of collaborative requirements planning.
2. Description of the Related Art
Requirements planning relates to the planning of requirements for a software system. Generally, the “requirements” for a software system refer to a set of artifacts such as files, records in a database and the like that define the software system in a form understood both by the consumers including the end-users and purchasing decision-makers, and the producers including the business analysts, architects, and developers of the software system. The process of specifying the requirements for a software system ensures that the consumers and producers both understand and agree on the requirements for the software system.
Traditionally, in the requirements planning process, either the consumers or the producers propose an initial set of requirements. Thereafter, the stakeholders to the requirements plan—namely, both the consumer and the producers—can convene to discuss the initially proposed requirements. The convention ultimately results in the production of a new version of requirements and the stakeholders can cycle through multiple different conventions until a version of the requirements plan has been approved by all stakeholders.
Notably, the understanding of what is desirable for the consumers in terms of requirements, and what is feasible for the producers in terms of meeting the requirements continually changes during the development of a software system. In order to satisfy the requirements of consumers with a deliverable, the requirements changes must be understood and approved by all the stakeholders. Consequently, the requirements management process must actively continue throughout the software development process.
Recognizing the fluid nature of requirements planning, the modern Extreme Programming (XP) development process mandates the gathering of all stakeholders (including consumers with approval responsibilities) into a single physical location for the lifetime of the software project. In an XP modeled development process, stakeholders continuously meet and have discussions as a group during the development cycle. The XP development process, however, cannot account for distributed development where the stakeholders cannot gather into a single physical location due to either a large number of stakeholders or the geographic distribution of the stakeholders. Additionally, the XP development process cannot account for an expanding stakeholder membership where new stakeholders lack the context of previous discussions collaboration.